The complete flow from human action to computer execution
Imagine you press "Save" on an image editor. That single human action will ripple through dozens of COA ideas.
The mayor/conductor; contains Control Unit (CU) and Data Path (ALU, registers)
Tiny notepads inside the CPU
The CPU's pantry (SRAM)
The backstage storeroom where programs run
The address translator and sticky notepad for translations
Long-term storage and the OS maps
Customs officers and couriers handling peripherals
Roads (data bus, address bus, control bus)
The hard drive, USB stick, printer, etc.
The city manager that coordinates big actions
The CPU almost always uses virtual addresses. That means the address must be translated to a physical RAM address before the memory access can complete.
The MMU checks the TLB (Translation Lookaside Buffer), a tiny, very fast cache of recent virtual→physical translations.
Great — the MMU quickly supplies the physical address
The MMU must walk the page table (possibly multi-level) — slower; the OS may be involved if the page isn't resident
With physical address in hand, the CPU checks the L1 cache for that physical address.
Instruction fetched in a cycle or two and placed into the Instruction Register (IR)
Lookup lower levels (L2, L3), then main memory (DRAM). Each miss adds latency
The CU decodes the instruction (opcode → micro-ops). If the CU is:
Combinational logic generates control signals right away (fast, inflexible)
The CU fetches microinstructions from a control store and executes them (flexible, slightly slower)
The instruction's operands are fetched from registers (fast) or from memory if needed (load). Addressing modes tell how to get operands:
Value is in the instruction itself
Value is in a register
Address is in the instruction
Address of address is in the instruction
Address is register + constant
Value is on the stack
CPU issues memory read/write on the address bus, control signals (read/write) on the control bus, and data transfers on the data bus.
If the needed block is not in cache, the system fetches it from main memory (DRAM). DRAM access is slower — tens to hundreds of cycles.
If the page is not present in main memory (page table entry invalid) → page fault:
DMA controller handles big transfers between disk and memory:
DMA takes some bus cycles
DMA uses bus for a long burst
Once done, DMA raises an interrupt to inform CPU; OS resumes any blocked process.
For disks, RAID or caching layers may serve or mirror data; disk controller may have its own buffer and microcontroller — the IOP idea at a smaller scale.
Every store updates cache and main memory (simpler, higher bus traffic)
Cache keeps the updated block marked dirty and writes back to memory later (saves bandwidth)
In multicore systems, hardware protocols (MESI-like) ensure all cores see a consistent memory view.
Cache line is modified in this cache only
Cache line is unmodified and exists only in this cache
Cache line is unmodified and may exist in other caches
Cache line is invalid
While data moves, the device may raise interrupts:
Decide which device gets CPU attention first
Saves CPU state (pushes registers onto stack), jumps to ISR (interrupt service routine), processes the event, and restores state
Buses carry address, data, and control lines. Arbitration handles who uses the bus (CPU, DMA, IOP).
Between devices and controllers, handshaking ensures both sides are ready: request → acknowledge → data transfer.
Serial links use synchronous (clocked, e.g., SPI/I²C) or asynchronous (UART — start/stop bits) communication; they include flow control (RTS/CTS or XON/XOFF) and error detection.
Strobe signals tell the receiver "read the data now" for parallel transfers — same idea applied with timing pulses in memory buses.
The "Save" action completes — the file is safely stored across RAM and disk, with caches and buffers managed efficiently.
When data isn't in cache
When address translation isn't in TLB
When page isn't in main memory (disk I/O)
When multiple components need the bus
Time to handle interrupts
Percentage of memory accesses found in cache
Percentage of address translations found in TLB
How busy the CPU is
Response time for operations
Work completed per second
Bigger, more associative caches; prefetching and smart replacement (LRU, LFU)
Larger TLBs and page size manipulation
Keep ALU busy; needs branch prediction and hazard handling
Offload I/O work from CPU
Reduce page faults via working set management
Multi-level buses and point-to-point high-speed links
COA studies both the machine's instruction behavior and how hardware is organized to run it fast and reliably:
ISA, instruction formats, addressing modes determine how the CPU asks for operands
Hardwired vs microprogrammed decide how control signals are generated
ALU, registers, and buses do the work when signals say "compute" or "move"
Registers → cache → RAM → disk → tape form the memory hierarchy balancing speed and cost
MMU, TLB, paging/segmentation give the illusion of large private address spaces and protect processes
Controllers, DMA, interrupts, IOPs connect the CPU to the outside world without overwhelming it
Buses, strobe, handshaking, serial protocols are the physical/electrical glue
COA is the art of making these pieces cooperate so a keyboard click becomes a saved file with good speed, correct data, and efficient hardware use.
| Component | Role in the flow |
|---|---|
| CU (hardwired / micro) | Decodes instructions, issues control signals |
| Registers, ALU | Fast compute and temporary storage |
| Cache (L1/L2/L3) | Rapid instruction/data access; hit/miss determines latency |
| MMU & TLB | Translate virtual→physical addresses; cache translations |
| Page table & OS | Map pages; handle page faults and swapping |
| DRAM | Main memory — slower than cache |
| Disk (HDD/SSD), RAID, Tape | Secondary and archival storage |
| DMA | Moves bulk data without CPU cycles |
| I/O controller / IOP | Manage specific device protocols and buffering |
| Bus / Handshake / Strobe / Serial | Physical transfer and synchronization |
| Interrupts / Priority | Devices notify CPU; priorities resolve conflicts |
Underneath the friendly interface of "Save" or "Open" is a carefully choreographed race: the Control Unit calls the play, the Data Path runs the play, memory and caches provide the ball, the MMU makes sure players are allowed on the field, and the I/O crews shuttle the result to long-term storage — all coordinated to make your action feel instant.
Calls the play
Runs the play
Provide the ball
Makes sure players are allowed on the field
Shuttle the result to long-term storage